[WIP] Upgrade spring-boot-starter from version 2.7.x to 3.3.x #58
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
#8 is the issue. |
mroyme
changed the title
|
Okay, I just found out this needs work. This causes problems with the way the project uses Jackson. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request type
./gradlew build --write-locksto refresh dependencies)Dependency upgrade: Upgrading spring-boot from version
2.7.+to3.3.+NOTE: Please remember to run
./gradlew spotlessApplyto fix any format violations.Changes in this PR
spring-boot-starter-webandspring-boot-starter-testfrom version2.7.+to3.3.+.javaxpackages tojakartapackages. See: Spring-Boot-3.0-Migration-Guide#jakarta-eejakarta.validation-api).@ConstructorBinding. See: @ConstructingBinding No Longer Needed at the Type LevelNote: Why Apache bVal and not Hibernate Validator or Spring Boot Validator?
A: Firstly, Spring Boot Validator transitively depends on Hibernate Validator, so using either of them provides the same underlying Bean Validation implementation.
The problem with using Hibernate Validator is that it breaks the existing tests.
What I noticed is that
validator.validate(...)would always raise twice the number of violations. One of which is the actual violation and the other with empty values. I tried to find the cause, and came across a few threads with some not so convincing explanations and workarounds, none of which seemed to work. And after spending a good few hours trying to figure the problem, I still couldn't understand why I was seeing that behavior.In the end, I gave BVal a shot, and it worked fine on the first try. Anyway, BVal supports Bean Validation 3.0, is TCK certified and is being updated frequently. So, I didn't see any reason not to go with it. Also, if we indeed want to use some different implementation in the future; we just have to remove the BVal dependency and add whatever else we want to use.